SDN网络中的协议按照功能可以分为管理层面协议与控制层面协议。以SDN控制器为界限，按照可编程接口的层级可以分为南向接口与北向接口。OpenFlow协议严格的来说，是一种控制层面的南向接口协议，而OVSDB管理协议，是管理层面的南向接口协议。

OVSDB管理协议(Open vSwitch Database Management Protocol，开放虚拟交换机数据库管理协议) 起初由VMware公司提出，负责管理开源的软件交换机（OpenvSwitch,OVS）的开放虚拟交换机数据库（OpenvSwitch Database,OVSDB），是一个用于实现对虚拟交换机的可编程访问和配置管理的SDN管理协议。OVSDB管理协议定义了一套RPC接口，用户可通过远程调用的方式管理OVSDB，主要包括通信协议（JSON-RPC）方法和所支持的OVSDB操作。OVS是OVSDB的主要应用，其数据模式由OVSDB schema（DB-SCHEMA）定义。

在学习OVSDB协议之前，我们先了解一下OVSDB协议的一些基本概念：

UUID:通用唯一识别码 (Universally Unique Identifier)

OVS: Open vSwitch，开放虚拟交换机，遵循开源Apache2.0许可

OVSDB: 用于配置Open vSwich的数据库。

JSON: JavaScript Object Notation，JS 对象标记，一种轻量级的数据交换格式。是OVSDB所使用的数据格式，由RFC4627定义。

JSON-RPC: JSON Remote Procedure Call ，以JSON为协议的远程调用服务由JSON-RPC定义。

Durable: 持久化，类似于非易失性磁盘存储。OVSDB支持选择一个事务是否是持久化的。

OVSDB管理协议主要管理的对象是OVSDB数据库，OVSDB协议提供了OVSDB的可编程性入口。OVSDB数据库是OVS的唯一数据库，而OVSDB协议也是OVS在管理层的唯一协议。

在SDN网络中，OVS通常作为OVSDB服务端，而控制器作为OVSDB客户端存在，负责给OVSDB服务端下发配置信息，并从OVSDB服务端收集信息。一个典型的OVSDB存在的SDN网络架构如图1所示：

图1 典型的OVSDB存在的SDN网络架构

需要知道的是，控制器通过OVSDB不仅可以管理OVS，也能用于管理硬件交换机。每一个OVS上都会有OVS 守护进程（daemon）用于接收控制器指令完成配置下发，OVS 守护进程（daemon）支持以下常见配置：

l 创建、修改、删除OpenFlow数据通道（网桥）

l 配置OpenFlow数据通道所连接的控制器集群

l 配置OVSDB服务器所连接的Manager集群

l 创建、修改、删除OpenFlow数据通道的端口

l 创建、修改、删除OpenFlow数据通道的Tunnel接口

l 创建、修改、删除队列

l 配置QOS策略，并将这些策略与队列相关联

l 收集统计信息

我们再来看看H3C的控制器、OpenFlow虚拟交换机与OVSDB之间的关系。整体架构和开源控制器、OVS架构相同，如图2所示：

图2 H3C的SDN网络架构

OVSDB管理协议通信使用JSON作为数据格式和通信协议格式，并基于JSON-RPC V1.0版本进行数据调用。JavaScript Object Notation (JSON)是用于结构化数据序列化的一种文本格式，由RFC4627定义。

一些关于JSON格式的规定：

l JSON 数据的书写格式是：名称/值对，例如：“firstName”:“Ray”。

l JSON值可以是数字、字符串、逻辑值、数组、对象或null。

l JSON对象在花括号中书写，可以包含多个数据（名称/值对）：{ "firstName":“Ray" , "lastName":"Fu" }。

l JSON数组结构表示为一对中括号包裹着0到多个值或对象，值之间用逗号分隔，例如[[{ "firstName":"Ray", "lastName":“Fu" }], [{ "first":“He" , "last":"Wan" }]]。

不同于普通的JSON实现，OVSDB的JSON实现有以下限制：

l 字符串中不能存在Null字节

l 仅支持UTF-8编码

OVSDB使用了JSON下述简化术语：, , , , , , , , .

OVS的配置数据库由一系列表组成，每个表都有若干栏目以及行。

OVSDB数据库模式通常由下列格式的JSON对象表示：

名称

值

可选性

说明

“name”

必选

数据库整体标识

“version”

必选

数据库模式版本

“cksum”

可选

实现定义的校验和

“tables”

{: , ...}

必选

体现表名和表模式的JSON对象

表1用JSON对象表示OVSDB数据库模式

OVSDB表模式常由下列格式的JSON对象表示：

名称

值

可选性

说明

“columns”

{: , ...}

必选

包含的表格的UUID、版本信息等

“maxRows”

可选

表格的最大行数

“isRoot”

可选

表格内是否存在强依赖关系

“indexes”

[*]

可选

用于标识表格列

表2 用JSON对象表示OVSDB表模式

OVSDB列模式通常由下列格式的JSON对象表示：

名称

值

可选性

说明

“type”

必选

列的类型

“ephemeral”

< boolean >

可选

数据是否持久化

“mutable”

可选

数据是否可修改

表3 用JSON对象表示OVSDB列模式

一个完整的OVSDB架构，包括控制器和OVS。

图3 完整的OVSDB架构

OVS包含三个重要的组件：OVSDB-Server、OVS-vSwitchd以及OVS内核模块，具体作用如下：

OVSDB-Server：OVS的数据库服务进程，用于存储虚拟交换机的配置信息（比如网桥、端口等），为控制器和OVS-vSwitchd提供OVSDB操作接口。

OVS-vSwitchd：OVS的核心组件，负责保存和管理控制器下发的所有流表，为OVS的内核模块提供流表查询功能，并为控制器提供OpenFlow协议的操作接口。

OVS内核模块：缓存某些常用流表，并负责数据包转发（由转发部分Forwarding Path负责），当遇到无法匹配的报文，该模块将向OVS-vSwitchd发送packet-in请求，获取报文处理指令。OVS内核模块可以实现多个datapath，每个datapath可以有多个vport。每个数据通路都包含一个Flow Table。

从OVSDB数据系统实现的角度来说，OVSDB整体的系统架构以及实现环境，包括：OVSDB Client、OVSDB Server、OVSDB数据库和OVSDB tool，如图4所示：

图4 OVSDB整体的系统架构以及实现环境

OVSDB-Server是OVS的数据库服务器端，位于Open vSwitch本地。OVSDB-Client则是OVS数据库客户端，通常为控制器，通过OVSDB 管理协议向OVSDB-Server端发送数据库配置和查询的命令。因此，OVS-Client又被称为管理者。OVSDB-Client通常运行在Open vSwitch 本地，即管理员可以在OVS本地以命令行方式输入数据库配置和查询命令。另外，OVSDB-Client也可以部署在远端，从而实现对OVSDB-Server的远程配置。OVSDB tool其实是OVS的命令行工具，包含一系列的OVS配置命令，常用的有：

l OVS-vsctl：查询和更新OVS-vswitchd的配置信息。

l OVS-appctl：发送命令来运行相关Open vSwitch守护进程。

l OVS-ofctl：查询和控制OpenFlow switches和controllers。

l OVS-pki：为OpenFlow switches创建和管理公钥框架。

OVSDB数据库有三级结构：表（table）、记录（record）和属性（column）。例如，在bridge表中，每一个record就是一个网桥实例的信息集合，其中uuid和datapath_id等就是这条record的属性。Open_vSwitch表属于根表，一般有且只有一个record，属性有uuid、版本、系统版本和网桥bridges(当无网桥时则为空[])。这些都是可以通过OVS-vsctl list表名（如Open_vSwitch、bridge等表）来查询其具体内容的，OVSDB数据库的表（table）类型多种多样，具体列举如下：

表4 OVSDB数据库的表类型

控制器和OVS交互的JSON报文中可能携带多种table信息。

Bridge Table（网桥表）主要记载了OVS内网桥的配置信息。一个Bridge record通常代表着一个以太网交换机，内含一个或多个端口（Ports）,端口的信息由Bridge Ports column记录。网桥表的核心特性如下：

l name 不变的字符串 (表中唯一)

l ports 端口集合

l mirrors 镜像集合

l flood_vlans VLAN泛洪范围（0-4095）

网桥表还承载了OpenFlow的配置，列举如下：

l controller 控制器集合

l flow_tables 流表

l fail_mode 逃生模式

l flood_vlans VLAN泛洪范围（0-4095）

l datapath_id 可选字段

以一个具体的网桥表的内容举例，如下图可以看到，表中包含了OpenFlow协议版本，fail_mode信息，网桥的名称和模式，端口的集和，网桥的特性（datapath-id和是否使能LLDB）以及控制器的相关信息：

图5 网桥表的内容举例

Port Table(端口表)描述的网桥内的端口信息。通常来说，一个端口会有一个interface（接口），该接口指向自己的接口属性。这样的一个接口逻辑上来说会和一个物理上的以太网交换机的接口进行连接。端口的核心特性列举如下：

l name 不变的字符串 (表中唯一)

l interfaces 一个或多个接口

此外，端口表中还包含了端口的VLAN 配置，注意包括：

l vlan_mode access,trunk等VLAN模式选项

l tag VLAN Tag（0-4095）

当一个端口对应的interface接口不止一个时，通常是由于做了端口聚合Bonding，端口表中关于聚合的主要配置是：

l bond_mode 主备、负载分担聚合模式选项

我们以一个端口表的内容举例如下，可以看到端口表内包括的端口的名称，包含的接口名称，聚合模式等信息：

图6 端口表的内容举例

Interface Table（接口表）主要描述的就是端口内的接口信息了。接口表的核心特性有：

l name 不变的字符串 (表中唯一)

l ifindex 可选整数（0-4,294,967,295）

l mac 可选

此外，接口表还会描述自己的Openlow Port编号：

l ofport 可选整数

以及接口的类型：

l type 接口类型

我们以一个接口表的内容举例如下，可以看到接口表内包含了名称、类型ofport等信息：

图7 接口表的内容举例

Open_vSwitch Table是整个OVSDB数据库的根表，他包括主要描述OVS守护进程（deamon）的配置信息，一个Open_vSwitch Table只会有一个记录record，包含的必选配置为：

l bridges bridges集合

此外，Open_vSwitch Table还包含了状态信息，制定下一个或当前配置：

l next_cfg 整数

l cur_cfg 整数

我们来看一个典型的Open_vSwitch Table包含的信息：

图8 虚拟交换机表的内容举例

OVSDB RPC方法遵从JSON-RPCV1.0规范：每个请求包括方法名称、参数以及请求ID；每个回应包括了结果对象、错误对象以及匹配ID。

请求(Request)举例：

{ "method": "echo", "params": ["Hello JSON-RPC"], "id": 1}

l method：表示要调用的方法

l params：表示参数的数组

l id：表示这次请求是需要响应的，服务方需要提供一个同样是id为1的响应信息。

响应（response）举例：

l { "result": "Hello JSON-RPC", "error": null, "id": 1}

l result：表示返回结果，如果出错result必须为null

l error：表示出错，如果请求成功，则error必须为null

l id：表示为此响应对应的请求

OVSDB Server必须能实现所有的OVSDB PRC方法，OVSDB Client则必须能实现“Echo”及其他所有必要的方法。以下列举常见OVSDB RPC方法：

表5 常见OVSDB RPC方法

OVSDB的数据库操作主要是指的上一节中，Transact方法request请求中参数一栏的operation操作：

"params": [, *]

OVSDB的数据库操作可分为很多种，每一个OVSDB数据库操作都是一个JSON对象，主要包括Insert、Select、Update、Mutate、Delete、Wait、Commit、Abort、Commen、Assert操作。

OVS是产品级的虚拟交换机，大量应用在生产环境中，支撑整个数据中心虚拟网络的运转。OVS基于SDN的思想，将整个核心架构分为控制面和数据面，数据面负责数据的交换工作，控制面实现交换策略，指导数据面工作。前面我们讲到过，OVSDB是OVS的数据库，OVSDB管理协议最重要的应用就是OVS了。从整体上看，OVS可以划分为三个部分，管理面、数据面和控制面。数据面以用户态的OVS-vswitchd和内核态的datapath为主的转发模块，以及与之相关联的数据库模块 OVSDB-Server组成。控制面主要是由OVS-ofctl模块负责，基于OpenFlow协议与数据面进行交互。而管理面则是由OVS提供的各种工具来负责，这些工具的提供也是为了方便用户对底层各个模块的控制管理，提高用户体验。

图9 OVS应用架构

上图是一个完整的OVS应用架构，可以看到OVSDB运行在OVS的用户态，对OVSDB-Server负责。具体相关概念解释如下：

l OVS-vswitchd：switch的守护程序，实现交换功能，和Linux内核兼容模块一起，实现基于流的交换flow-based switching。

l OVSDB-Server：轻量级的数据库服务，OVSDB提供的RPC接口。

l OVSDB：轻量级数据库，主要保存了整个OVS的配置信息，包括接口、VLAN等。OVS-vswitchd会根据OVSDB数据库中的配置信息工作。

l OVS-dpctl：一个工具，用来配置switch内核模块，可以控制转发规则。

l OVS-vsctl：主要是获取或者更改OVS-vswitchd的配置信息，更新OVSDB数据库。

l OVS-appctl：主要是向OVS守护进程发送命令的。

l OVS-ofctl：用来控制OVS作为OpenFlow交换机工作时候的流表内容

我们再来看看商用OVS的实现，以H3C为例。H3C S1020V基于开源Open vSwitch结构进行开发，分为用户态和内核态.用户态负责转发表项学习和存储，内核态负责转发报文,用户态OVS-vswitchd进程通过OpenFlow协议学习转发表项以及报告vSwitch端口状态变化,用户态OVSDB-Server进程为轻量级数据库，通过OVSDB协议获取vSwitch配置，并进行配置存储和下发,内核态vSwitch kernel module通过netlink或者vmklink协议学习用户态转发表项和配置，并对报文进行转发。

图10 OVS的实现

H3C的S1020V遵循OVS的架构，当S1020V与控制器进行交互时，也遵循OVS的交互范式：

图11 S1020V与控制器的交互

时光飞逝，斗转星移，距离OVSDB规范正式发布已经有五年的时间了。随着SDN和虚拟化技术的发展，虚拟交换机依靠灵活、弹性、经济的特性已经逐渐取代部分传统硬件交换机，在数据中心网络中占据一席之地。尽管如此，OVSDB和OVS仍然存在着部分功能短板，例如安全性、对协议栈的兼容、容灾与逃生等。当前我们已经看到各大开源组织和厂商在这方面的努力和尝试，相信在不久的将来，OVSDB将与OVS一起持续发热，大放异彩。